REMARKS 

The above amendments to the above-captioned application along with the following 
remarks are being submitted as a full and complete response to the Official Action dated 
October 31, 2007. In view of the above amendments and the following remarks, the 
Examiner is respectfully requested to give due reconsideration to this application, to indicate 
the allowability of the claims, and to pass this case to issue. 

Status of the Claims 

Claims 1, 3-5 and 7-15 are under consideration in this application. Claims 2 and 6 are 
being cancelled without prejudice or disclaimer. Claims 1 and 3-5, and 7-10 are being 
amended, as set forth in the above marked-up presentation of the claim amendments, in order 
to correct formal errors and/or to better recite or describe the features of the present invention 
as claimed. New claims 11-15 are being added. 

All the amendments to the claims are supported by the specification. Applicants 
hereby submit that no new matter is being introduced into the application through the 
submission of this response. 

Formality Rejection 

Claims 1-10 were objected to for informalities. Claims 5-7 were rejected under 35 
U.S.C. §101 for claiming non-statutory subject matter. As indicated, the claims are being 
amended as required by the Examiner. Accordingly, the withdrawal of the outstanding 
informality rejection is in order, and is therefore respectfully solicited. 

Prior Art Rejection 

Claims 1, 5 and 8 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Thorsteinson et al. (US 2003/012694), claims 2-4, 6-7 and 9 were rejected under 35 U.S.C. 
§103 (a) as being unpatentable over Thorsteinson "694 in view of Applicant's Admitted Prior 
Art ("APA"); and claim 10 was rejected over Thorsteinson '694 in view of Biederman (US 
7,006,526). These rejections have been carefully considered, but are most respectfully 
traversed, as more fully discussed below. 

The data delivery server (for example, the embodiment depicted in Figs. 1-2) of the 
present invention connected to a mobile terminal by way of a network for delivering an IP 
packet 24 having data packets 22a, 22b recorded internally of payload, as now recited in 
claim 1, comprises: a search module 1 for determining a maximum value of a size of one IP 
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packet capable of passing through a channel on said network extending from said data 
delivery server to said mobile terminal, a packet generating module 4 for determining a 
number of said data packets to be stored in the payload of the IP packet on the basis of said 
maximum value of a size of one IP packet and for storing the determined number of said data 
packets into the payload of said IP packet thereby generating said IP packet without 
fragmenting said IP packet (p. 5, line 13; "the packet suffering no fragmentation" p. 8, line 
11), an input/output unit for delivering said IP packet generated by said packet generating 
module , and a move detecting module designed for accepting a move message of said mobile 
terminal (claim 2). The search module 1 determines said maximum value of a size of one IP 
packet depending upon a current channel on a current network ( "exchange or switching of the 
network doe to the move of the terminal " p. 9. lines 3-5) connecting between said data 
delivery server and said mobile terminal after a move of said mobile terminal ("determining 
an MTU o f a network extending between the server and a receiver terminal upon starting o f 
delivery or dispatch o f the data packet" p. 6, lines 3-5) by sending out one ore more search 
packets each of which excludes data to be included in the payload of said IP packet (83 in 
Fig. 8; p. 17, lines 10-14), when the move of said mobile terminal is detected by said move 
detecting module (claim 2). 

The invention of claim 8 is directed to a data delivery system comprised of a server 
for delivering data including data packets additionally recorded internally of payload of an IP 
packet and a mobile terminal connected to said server by way of a network for receiving said 
data. Either said server or said mobile terminal (Embodiment 2; "the terminal searches the 
MTU and massage the results of the search to the server" p. 15, lines 14-15) comprises: the 
components and functions of the data delivery server of claim 1 . 

The invention of claim 5 is directed to a data delivery software embedded in a 
computer readable storage medium to carry out data delivery a microprocessor and an 
input/output unit of either said server or said mobile terminal of claim 8. 

The present invention thus eliminates the fragmentation of IP packet in a 
communication channel or path thereby preventing increase of load imposed on network 
appliance from increasing due to fragmentation in a heavy traffic situation. The present 
invention also prevents increase of a load imposed on a receiver terminal due to 
reconstruction or restructuralization of the fragmented packet (p. 5, lines 12-12). 

Applicants respectfully submit that the cited references and their combination do not 
teach or suggest that "determining [[the]] a number of said data packets to be stored in the 
payload of the IP packet on the basis of said maximum value of a size of one IP packet and 
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for storing the determined number of said data packets into the payload of said IP packet 
thereby generating said IP packet without fragmenting said IP packet" , and " determining said 
maximum value of a size of one IP packet depending upon a current channel on a current 
network connecting between said data delivery server and said mobile terminal after a move 
of said mobile terminal by sending out one or more search packets each of which excludes 
data to be included in the payload of said IP packet, when the move of said mobile terminal is 
detected by said move detecting module " as the present invention. 

In contrast, Thorsteinson and APA merely decide MTU between two Fixed IP hosts. 
For example, Path MTU discovery (PMTUD) is a technique in computing for determining the 
maximum transmission unit ("MTU") size on the network path between two fixed IP hosts 
with a view to avoiding IP fragmentation. Path MTU discovery works by setting the DF 
(Don't Fragment) option bit in the IP headers of outgoing packets. Then, any device along the 
path whose MTU is smaller than the packet will drop it ("try-and-error"), and send back an 
ICMP "Fragmentation Needed" message containing its MTU, allowing the source host to 
reduce its assumed path MTU appropriately. The process repeats until the MTU is small 
enough to traverse the entire path without fragmentation. If the path MTU changes after the 
connection is set up and is lower than the previously determined path MTU, the first large 
packet will cause an ICMP error and the new, lower path MTU will be found. Conversely, if 
PMTUD finds that the path allows a larger MTU than what is possible on the lower link, the 
OS will periodically re-probe to see if the path has changed and now allows larger packets. 
On Linux this timer is set by default to ten minutes. 

In PMTUD, the update of MTU is caused by the change of a piece of hardware/device 
along the path, rather than due to the movement of a destination host or a mobile terminal as 
the present invention . In addition, PMTUD takes a try-and-error approach which actually 
drop the packets including meaningful payload data. On the other hand, the present invention 
sends out one ore more search packets each of which excludes data to be included in the 
payload of said IP packet. 

As to the prior art ping, it is also applied between two fixed points (rather than one 
fixed point vs. one mobile point as the present invention) in a network, such as a computer 
network, to test whether a particular host is reachable across an IP network. It works by 
sending ICMP "echo request" packets to the target host and listening for ICMP "echo 
response" replies. Ping estimates the round-trip time, generally in milliseconds, and records . 
any packet loss, and prints a statistical summary when finished. 



Biederman fails to compensate for the deficiencies of Thorsteinson and APA as 
discussed above. 

Applicants contend that the cited prior art references and their combinations fail to 
teach or disclose each and every feature of the present invention as recited in at least 
independent claims 1, 5 and 8. As such, the present invention as now claimed is 
distinguishable and thereby allowable over the rejections raised in the Office Action. The 
withdrawal of the outstanding prior art rejections is in order, and is respectfully solicited. 



In view of all the above, clear and distinct differences as discussed exist between the 
present invention and the prior art references upon which the rejections in the Office Action 
rely, Applicant respectfully contends that the prior art references cannot anticipate the present 
invention or render the present invention obvious. Rather, the present invention as a whole is 
distinguishable, and thereby allowable over the prior art. 

Favorable reconsideration of this application is respectfully solicited. Should there be 
any outstanding issues requiring discussion that would further the prosecution and allowance 
of the abqve-captioned application, the Examiner is invited to contact the Applicant's 
undersigned representative at the address and telephone number indicated below. 



3110 Fairview Park Drive, Suite 1400 
Falls Church, Virginia 22042 
(703) 641-4200 

January 25, 2008 

SPF/JCM/JT 



Conclusion 



Respectfully submitted, 




Stanley P. Fisher 
Registration Numbe r^ 24,344 



Reed Smith LLP 
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